Fix 15 open pnpm issues across hosted, vendored and agent modes - #1007

…919)

The hosted pnpm unwind (rollback / remove, and the hosted -> vendored
takeover and eject that share it) restored each pinned pnpm-lock.yaml
resolution from the version document of the default registry
(SOCKET_NPM_REGISTRY, npmjs when unset). restore_pnpm_locks still called
the default-registry `fetch_dists`; the project-registry lookup added
for #908 (`fetch_dists_on`) was wired only into yarn berry and vlt. The
lock-sibling `.npmrc` `registry=` was read, but only to decide whether a
`tarball:` is written, never to pick the registry the dist comes from,
and `@scope:registry` was not read at all. So for a project resolving
against a mirror:

- a CDN-style mirror `tarball:` came back as a bare `{integrity}`,
  because npmjs's URL is conventional, and a cold frozen install 404s;
- under lockfile-include-tarball-url, npmjs's dist.tarball replaced the
  mirror URL pnpm had recorded.

Both exited 0.

pnpm resolves a name against its `.npmrc` `@scope:registry` when the
name is scoped and that key is set, otherwise against `registry`. The
new `pnpm_lookup_registry` encodes that rule, and the restore now uses
it for two things: as the per-name registry for `fetch_dists_on`, which
also gives the existing `upstream_registry_fallback` warning and
default-registry fallback when the mirror can't be read, and in the
`registry_derives_tarball` decision, so a scoped package's conventional
scope-registry URL stays derived. A value that still holds an unexpanded
`${VAR}` is read as unset (today's default-registry behaviour) and is
never fetched as a literal URL.

CLI_CONTRACT.md: the npm-family upstream bullet, the SOCKET_NPM_REGISTRY
row and the upstream_registry_fallback row now list pnpm's `.npmrc`
`registry` / `@scope:registry` next to berry and vlt.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

`scan --mode agent packages/a` in a pnpm workspace scanned 0 packages
and exited 0, while `rollback packages/a` selected the member's
dependencies.

Root cause: the npm crawler keeps one CrawledPackage per name@version
(`merge_scan_events`' `seen` set), recorded at the first copy the walk
meets. In a pnpm workspace that is the root `node_modules/.pnpm` store
entry, never the member's `packages/a/node_modules/<dep>` link; in a
yarn classic / npm workspace with a version conflict it is whichever
member's nested copy the readdir order reaches first. Scan's PATH filter
tested only that one recorded path, so the contract rule "in scope iff
ANY installed copy sits under a matching path" was never honored for
the other copies. Rollback resolves candidates through
`find_all_packages_for_rollback`, which returns every copy, hence the
divergence.

Fix: keep the cheap first pass over the recorded paths, then resolve
the purls that missed to every installed copy with the same
enumeration rollback's path targets use (new
`find_all_packages_for_rollback_reusing`, which reuses the crawl's npm
roots), and admit a purl when any copy matches. A path-scoped run now
keeps the npm crawl snapshot so the roots are not rediscovered. The
crawler's per-purl dedup is unchanged; apply already patches every copy
of a selected purl. Unscoped scans are untouched.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

#888 made hosted and vendored modes refuse a pnpm project with its own
v9 lock and no pnpm-workspace.yaml of its own whenever any ancestor held
a pnpm-workspace.yaml (redirect_pnpm_settings_elsewhere,
vendor_pnpm_settings_elsewhere). governing_workspace_file took the
nearest ancestor file without asking whether its `packages:` globs list
the project. pnpm 11.28+ and 12 install a directory the nearest file
does not list (an examples/ app, a checkout under an unrelated
workspace) standalone: its own lock, and settings read only from its own
pnpm-workspace.yaml. So both refusals pointed at remedies that do
nothing, and neither mode could patch a project 4.0.0 handled.

governing_workspace_file now reads the nearest regular ancestor file
(FIFO-safe reader) and returns it only when it lists the project, as
probed on pnpm 11.28.5 and 12.10.1:
- no `packages:`, a null or an empty list: root-only workspace, so no;
- otherwise some pattern matches and no `!` pattern does (pnpm's globber
  treats every negation as an ignore, wherever it sits).
A file that does not parse, or a pattern with braces, classes or
extglobs the matcher does not model, still counts as listing the
project, so #880/#881 stay refused. With no governing file, hosted
creates the project's own pnpm-workspace.yaml with trustLockfile: true
and vendored wires its override there, as before #888.

The glob matcher used by the package.json workspaces check (#884) moves
to utils/workspace_globs.rs so both checks share it. CLI_CONTRACT.md
scopes both codes to members listed by the root's `packages:` globs.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…854)

Vendored pnpm takes over a user's exact-version override of the package
it vendors (the pin already forces that version, so redirecting the same
key keeps its meaning), but the pre-flight only classified package.json
`pnpm.overrides`. On pnpm 10.5+ (always on 11/12) the override lives in
pnpm-workspace.yaml `overrides:`. With no package.json override the
effective key fell back to our canonical `name@version`, so a bare-key
pin (`left-pad: 1.3.0`) in the workspace file and its lock mirror were
refused as `vendor_override_conflict`, with a detail claiming the lock
"does not match package.json's `left-pad@1.3.0`". The versioned-key pin
only worked because it happened to equal our canonical key.

- The per-entry Insert / Ours / Takeover / conflict rules are factored
  into classify_override_entries, shared by classify_pkg_override and a
  new classify_ws_override (modern locks only; legacy pnpm never reads
  the workspace file). The effective key comes from whichever file
  carries the override; package.json and the workspace file pinning
  under different keys refuses naming both files.
- check_lock_override names the file the effective key came from (or
  says it is the key vendoring would add), and conflict details name
  pnpm-workspace.yaml when that is where the override lives.
- workspace_overrides_govern now counts any workspace override key the
  lock records, vendored values included. Before, once a workspace-only
  takeover made the value ours, a re-run (or vendoring another package)
  saw no user key and wrote a package.json copy that shadows the
  workspace overrides on pnpm 10 (#360 twin).

The #853 CLI fixture that used a bare workspace exact pin as its
"refused" trigger now uses a range, and a new CLI test pins the
takeover. CLI_CONTRACT.md documents the takeover exception.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

…633)

In a pnpm (or Bun isolated) workspace, agent-mode `apply` reported every
package a member links twice: once `applied`, then a phantom `skipped` /
`already_patched` for the same purl, and every re-run counted one extra
skip per member-linked package. `rollback` double-counted
`alreadyOriginal` the same way.

Root cause: the multi-copy resolver (`find_all_packages_for_purls` /
`find_all_packages_for_rollback`) runs `find_by_purls` once per
`node_modules` root. The workspace root pass records the store entry
`node_modules/.pnpm/<pkg>@<ver>/node_modules/<pkg>` and the member pass
records the member's `packages/a/node_modules/<pkg>` link to it.
`merge_npm_copies` dedupes by literal path, so both spellings of one
directory survive and the apply/rollback per-copy loops visited the same
physical copy twice.

Fix: collapse each npm purl's copies to distinct real directories at the
two sites that act per copy (apply's copy loop and rollback's restore
targets), keeping the first-found spelling, via a new
`distinct_npm_copies` built on the canonical-path helper
`distinct_install_dirs` (moved from apply.rs to ecosystem_dispatch.rs,
where PyPI apply keeps using it). The resolver map itself still carries
every spelling on purpose: path targets (`scan --mode agent packages/a`,
`rollback packages/a`, #778) match copies textually through the member's
link, and deduping there would make those scopes select nothing.
Genuinely distinct copies (nested duplicates, store peer variants,
bundled copies) have distinct real paths and are unaffected; a path that
can't be canonicalized is kept as-is.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

The hosted pnpm unwind (rollback / remove) decides whether a restored
pnpm-lock.yaml resolution gets a `tarball:` from PnpmTarballPolicy. That
policy read `lockfileIncludeTarballUrl` from pnpm-workspace.yaml, else
`lockfile-include-tarball-url` from .npmrc, whatever pnpm major wrote
the lock. But pnpm <= 9 ignores pnpm-workspace.yaml settings and pnpm
11/12 ignore pnpm settings in .npmrc, so in those projects the lock has
no `tarball:` fields, yet rollback/remove wrote the registry's
dist.tarball into every restored resolution: not byte-exact, and each
restored package hard-pinned to that registry.

The decision now follows what pnpm actually did, strongest signal first:

1. The lock's own unpinned registry resolutions (registry key per the
   shared pnpm_registry_key rule, integrity, no git/directory fields,
   tarball neither hosted nor `file:`). With the setting on pnpm writes
   `tarball:` on every one, so a single bare one proves it off; failing
   that, a tarball pnpm could have derived proves it on. Unconventional
   URLs are recorded either way and give no evidence.
2. The settings file the installed pnpm major reads: the major comes
   from node_modules/.modules.yaml `packageManager` (JSON on pnpm 10+,
   YAML before), else package.json's corepack `packageManager`, else a
   pre-9 lockfileVersion or a shrinkwrap.yaml means pnpm <= 8. <= 9 reads
   .npmrc only, 10 the workspace file then .npmrc, 11+ the workspace
   file only.
3. With neither (no install record, only pinned entries, e.g. a fresh
   clone or a Rush lock), pnpm 10's reading, as before.

The splice logic and the unconventional-URL branch (#557) are unchanged.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

pnpm's globber reads `packages:` with dot matching off: on pnpm 12.10.1,
`packages: ['**']` leaves `.github/actions/demo` standalone with its own
lock, as do `packages/**` for `packages/.x/demo` and `packages/*` for
`packages/.hidden`. The shared matcher let `*`, `?` and `**` match those
components, so governing_workspace_file still named the root file for
them and hosted / vendored refused with redirect_pnpm_settings_elsewhere
/ vendor_pnpm_settings_elsewhere, pointing at a file pnpm never reads
for that directory.

lists_as_member now uses glob_matches_no_dot: a wildcard component never
matches a path component starting with `.` unless the pattern component
itself starts with `.` (`.github/**` still lists it). The npm/yarn
`workspaces` caller keeps its current matching.

Tests: the probed dot cases in the core membership test and at the
refusal level; the refusal test's settings-only root now carries no
trust key (`trustLockfile: false` short-circuited the refusal on main
too, so it never exercised the membership rule); and the #880 doc
comment moves back onto its own test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

With Rush subspaces enabled, each subspace keeps its pnpm lock and the
repo-state.json that carries its pnpmShrinkwrapHash side by side under
common/config/subspaces/<name>/, and there is no
common/config/rush/repo-state.json. The hosted engine rewrote the
subspace locks but gated redirect_rush_repo_state_stale on the one fixed
common path (RUSH_REPO_STATE_REL), so the warning never fired and
`rush install` with preventManualShrinkwrapChanges failed on the hash
check with no hint.

The gate now pairs each rewritten Rush lock with the repo-state.json in
its own directory (the common lock still maps to RUSH_REPO_STATE_REL), so
a subspace rewrite warns on its subspace's file and a common-only rewrite
is not flagged by an unrelated subspace's file. The in-memory host's
selector fetches common/config/subspaces/*/repo-state.json presence-only
as well, so disk and memory runs agree. Docs and CLI_CONTRACT name the
per-subspace file.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

pnpm 11+ writes the env lockfile (configDependencies /
packageManagerDependencies) as a first YAML document ahead of the project
lock, and records its resolutions as a bare `{integrity}` even under
lockfileIncludeTarballUrl (verified with pnpm 11.27.0 and
`pnpm add --config is-number@7.0.0`). The tier-1 evidence scan walked every
`packages:` section, so that one bare config dependency proved the setting
off and rollback/remove restored a pinned entry without its `tarball:`,
exiting 0 with a lock that was not byte-exact.

The evidence scan now reads only the main document (after the last `---`
marker), through a new shared grammar::main_document helper.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Hosted mode creates `packages: ['.']` + `trustLockfile: true` for every
v9 root lock with no pnpm-workspace.yaml, and vendored mode creates the
same scaffold for its `overrides:` mirror. On pnpm 9.0.0-10.4.x that file
turns a single-package project into a root-only workspace, where
`pnpm add <pkg>` fails with ERR_PNPM_ADDING_TO_ROOT unless given `-w`
(10.5.0 is the first release that adds normally). Those releases read
neither setting from the file: `trustLockfile` is pnpm >= 11, and
workspace `overrides:` are read from 10.5 on.

Direction taken: a version-gated scaffold, not `ignoreWorkspaceRootCheck`.
When the project has no pnpm-workspace.yaml and every pnpm pin it
carries (at least one) names 9.0-10.4, neither mode creates the file.
The pins are the installed node_modules/.modules.yaml `packageManager`
(YAML on pnpm 9, JSON on 10+) and package.json `packageManager`,
`devEngines.packageManager` and `engines.pnpm`, all read with the
FIFO-safe regular-file readers. A pin naming a later pnpm, a range
reaching past 10.4, an unparseable pin, or no pin keeps the scaffold, so
pnpm >= 11 never loses the setting it needs.

- Hosted: the new redirect_pnpm_trust_lockfile variant names the pins,
  says why nothing was written, and gives the pnpm >= 11 recovery
  (re-run the scan, or `pnpm install --trust-lockfile`). A created
  scaffold's detail now notes the `pnpm add -w` caveat.
- Vendored: package.json `pnpm.overrides` and the lock are wired as
  before, the workspace mirror is skipped; a later vendor on pnpm >= 10.5
  adds it, and revert undoes all three byte-for-byte. The "Commit ..."
  next step names pnpm-workspace.yaml only when the file exists.
- package.json `packageManager` parsing moves to
  utils/package_manager.rs, shared with the yarn migration check.

Tests cover both modes: core unit tests for the pin reader, vendor and
revert (including the upgrade path), in-memory and in-process hosted
runs including heal-on-rerun after an upgrade and rollback removing the
created file, and the real-pnpm e2e legs now expect no file on pnpm 9.
CLI_CONTRACT.md, docs/ecosystems.md and docs/testing/pnpm-compatibility.md
describe the rule.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

Main (#1058) made DiskSnapshot::root private behind ProjectView::disk_root
and added three RewriteOptions fields; read the root through disk_root()
and fill the new fields in the test initializer.

Co-Authored-By: Claude <noreply@anthropic.com>

The governing workspace root is reported without Windows' \\?\ prefix
(governing_workspace_file strips it), but the test built its expected
value from the canonicalized tempdir, which keeps it. The test failed on
windows-latest only. Strip the prefix from the expectation the same way.

Co-Authored-By: Claude <noreply@anthropic.com>